% SPDX-License-Identifier: GPL-3.0-or-later OR CC-BY-SA-4.0
\section{App Details Page}\label{sec:app-details-page}
\textbf{App Details} page consists of 11 (eleven) tabs. It basically describes almost every bit of information an app
can have including all attributes from app manifest, permissions, \hyperref[ch:app-ops]{app operations}, signing info,
etc.

\subsection{Colour Codes}\label{subsec:app-details-colour-codes}
List of background colours used in this page, and their meaning:
\begin{itemize}
    \item \colorbox{red}{\textcolor{black}{Red (day)}} / \colorbox{AMDarkRed}{\textcolor{white}{dark red (night)}}
    -- Any app op or permission that has the dangerous flag is marked as red. Components that are blocked within App
    Manager are also marked as red

    \item \colorbox{AMLightRed}{\textcolor{black}{Light red (day)}} / \colorbox{AMVeryDarkRed}{\textcolor{white}{very
    dark red (night)}} -- Components that are disabled outside App Manager have these colors. It should be noted that a
    component that is marked as disabled does not always mean that it is disabled by the user: It could be disabled by
    the system as well or marked as disabled in the app manifest. Also, all components of a disabled app are considered
    disabled by the system (and by App Manager as well)

    \item \colorbox{AMVividOrange}{\textcolor{black}{Vivid orange (day)}} / \colorbox{AMVeryDarkOrange}{
        \textcolor{white}{very dark orange (night)}} -- Ad or tracker components

    \item \colorbox{AMSoftMagenta}{\textcolor{black}{Soft magenta (day)}} / \colorbox{AMVeryDarkViolet}{
        \textcolor{white}{very dark violet (night)}} -- Currently running services
\end{itemize}

\subsection{App Info Tab}\label{subsec:app-info-tab}
\textbf{App Info} tab contains general information about an app. It also lists many actions that can be performed within
this tab. A complete description is given below:

\subsubsection{General Information}\label{subsubsec:app-info-general-information}
The list below is in the same order as listed in the App Info tab.
\begin{itemize}
    \item \textbf{App Icon.} The application icon. If an app doesn't have an icon, the system default icon is displayed.

    \item \textbf{App Label.} The application label or application name.

    \item \textbf{Version.} Application version is divided into two parts. The first part is called \textit{version
    name}, the format of this part varies but it often consists of multiple integers separated by dots. The second part
    is called \textit{version code} and it is closed under first brackets. Version code is an integer which is usually
    used to differentiate between app versions (as version name can often be unreadable by a machine). In general, new
    version of an app has higher version code than the old ones. For instance, if \texttt{123} and \texttt{125} are two
    version codes of an app, we can say that the latter is more updated than the former because the version code of the
    latter is higher. For applications that depend on platforms (mobile, tabs, desktops, etc.), these version numbers
    can be misleading as they use prefixes for each platform.

    \item \textbf{Tags.} (Also known as tag clouds) Tags include the basic, concise and most useful info of an app.
    Tags contain \textit{tracker info} (i.e.\ number of tracker components), \textit{app type} (user app or system app
    and whether the app is an updated version of the system app or if the app is installed systemless-ly using Magisk),
    \textit{running} (i.e. one or more services of the app is running in the background), \textit{split APK info} (i.e.
    \ number of splits), \textit{debuggable} (the app is a debug version), \textit{test only} (the app is a test only
    app), \textit{large heap} (the app has requested a large heap size), \textit{stopped} (the app is force stopped),
    \textit{disabled} (the app is disabled), \textit{KeyStore} (the app has items in the Android KeyStore),
    \textit{no code} (the app doesn't have any code associated with it), \hyperref[sec:terminologies]{\textit{SSAID}},
    \textit{netpolicy} (network policy such as background data usage), and \textit{battery optimization}.
    The importance of including \textit{test only} and \textit{debuggable} is that app with these properties can do
    additional tasks or these apps can be \texttt{run-as} without root which can cause potential security problems
    if these apps store any private information.
    \textit{Large heap} denotes that the app will be allocated a higher amount of memory (RAM) if needed.
    While this may not be harmful for most cases, any suspicious apps requesting large heap should be taken seriously.

    \item \textbf{Horizontal Action Panel.} This is an action panel containing various actions regarding the app. See
    \Sref{subsubsec:horizontal-action-panel} for a complete list of actions available here.

    \item \textbf{Paths \& Directories.} Contains various information regarding application paths including \textit{app
    directory} (where the APK files are stored), \textit{data directories} (internal, device protected and externals),
    \textit{split APK directories} (along with the split names), and \textit{native JNI library} (if present). JNI
    libraries are used to invoke native codes usually written in C/C++. Use of native library can make the app run
    faster or help an app use third-party libraries written using languages other than Java like in most games. You can
    also open these directories using your favourite file managers (provided they support it and have necessary
    permissions) by clicking on the launch icon on the right-hand side of each item.

    \item \textbf{Data Usage Since Last Boot.} A rather self explanatory option. But beware that due to some issues, the
    results might often be misleading and simply wrong. This part remains hidden if \textit{Usage Access} permission is
    not granted in newer devices.

    \item \textbf{Storage \& Cache.} Displays information regarding the size of the app (APK files), data and cache. In
    older devices, size of external data, cache, media and OBB folders are also displayed. This part remains hidden if
    \textit{Usage Access} permission is not granted in newer devices.

    \item \textbf{More Info.} Displays other information such as--
    \begin{itemize}
        \item \textbf{SDK.} Displays information related to the Android SDK. There are two (one in old devices) values:
        \textit{Max} denotes the target SDK and \textit{Min} denotes the minimum SDK (the latter is not available in old
        devices). It is best practice to use apps with maximum SDK that the platform currently supports. SDK is also
        known as \textbf{API Level}.
        \seealsoinline{\href{https://en.wikipedia.org/wiki/Android_version_history\#Overview}{Android Version History}}

        \item \textbf{Flags.} The application flags used at the time of building the app. For a complete list of flags
        and what they do, visit the
        \href{https://developer.android.com/reference/android/content/pm/ApplicationInfo\#flags}{official documentation}.

        \item \textbf{Date Installed.} The date when the app was first installed.

        \item \textbf{Date Updated.} The date when the app was last updated. This is the same as \textit{Date Installed}
        if the app hasn't been updated.

        \item \textbf{Installer App.} The app that installed this app. Not all app supply the information used by the
        package manager to register the installer app. Therefore, this value should not be taken for granted.

        \item \textbf{User ID.} The unique user ID set by the Android system to the app. For shared applications, same
        user ID is assigned to multiple applications that have the same \textit{Shared User ID}.

        \item \textbf{Shared User ID.} Applicable for applications that are shared together. Although it says ID, this
        is actually a string value. The shared application must have the same
        \hyperref[subsec:signatures-tab]{signatures}.

        \item \textbf{Main Activity.} The main entry point to the app. This is only visible if the app has
        \hyperref[subsubsec:activities]{activities} and any of those are openable from the Launcher. There's also a
        launch button on the right-hand side which can be used to launch this activity.
    \end{itemize}
\end{itemize}

\subsubsection{Horizontal Action Panel}\label{subsubsec:horizontal-action-panel}
Horizontal Action Panel, as described in the previous section, consists of various app-related actions, such as--
\begin{itemize}
    \item \textbf{Launch.} Application that has a launcher \hyperref[subsubsec:activities]{activities} can be launched
    using this button.

    \item \textbf{Disable.} Disable an app. This button is not displayed for already disabled apps or to users who do
    not have root or \hyperref[sec:adb-over-tcp]{ADB}. If you disable an app, the app will not be displayed in your
    Launcher app. Shortcuts for the app will also be removed. If you disable a user app, you can only enable them via
    App Manager or any other tool that supports it. There isn't any option in Android Settings to enable a disabled user
    app.

    \item \textbf{Uninstall.} Uninstall an app.

    \item \textbf{Enable.} Enable an app. This button is not displayed for already enabled apps or to users who do not
    have root or ADB\@.

    \item \textbf{Force Stop.} Force-stop an app. When you force stop an app, the app will not be able to run in
    background unless you explicitly open it first. However, this is not always true.

    \item \textbf{Clear Data.} Clear data from an app. This includes any information stored in the internal and often
    the external directories, including accounts (if set by the app), cache, etc. Clearing data from App Manager, for
    example, removes all the rules (the blocking is not removed though) saved within the app. Which is why you should
    always take backups of your rules. This button is not displayed to users who do not have root or ADB\@.

    \item \textbf{Clear Cache.} Clear app cache only. There is not any Android-way to clear app cache. Therefore, it
    needs root permission to clear cache from the app's internal storage.

    \item \textbf{Install.} Install an APK opened using any third-party app. This button is only displayed for an
    external APK that hasn't been installed.

    \item \textbf{What's New.} This button is displayed for an APK that has higher version code than the installed one.
    Clicking on this button displays a dialog consisting of differences in a version control manner. The information it
    displays include \textit{version}, \textit{trackers}, \textit{permissions}, \textit{components}, \textit{signatures}
    (checksum changes), \textit{features}, \textit{shared libraries} and \textit{SDK}.

    \item \textbf{Update.} Displayed for an app that has a higher version code than the installed app.

    \item \textbf{Reinstall.} Displayed for an app that has the same version code as the installed app.

    \item \textbf{Downgrade.} Displayed for an app that has a lower version code than the installed app.

    \item \textbf{Manifest.} Clicking on this button displays the app's manifest file in a separate page. The manifest
    file can be wrapped or unwrapped using the corresponding toggle button (on the top-right side) or can be saved to
    you shared storage using the save button.

    \item \textbf{Scanner.} Clicking on this button displays the app's tracker and library information. At first, it
    scans the app to extract a list of classes. Then the class list is matched with a number of signatures. After that,
    a scan summary is displayed.\\
    \seealsoinline{\hyperref[sec:scanner-page]{Scanner page}}

    \item \textbf{Shared Prefs.} Clicking on this button displays a list of shared preferences used by the app. Clicking
    on a preference item in the list opens the \hyperref[sec:shared-preferences-editor-page]{Shared Preferences Editor
    page}. This option is only visible to the root users.

    \item \textbf{Databases.} Clicking on this button displays a list of databases used by the app. This needs more
    improvements, and a database editor which might be added in the future. This option is only visible to the root users.

    \item \textbf{F-Droid.} Opens the app in your favourite \textit{F-Droid} client.

    \item \textbf{Store.} Opens the app in \textit{Aurora Store}. The option is only visible if \textit{Aurora Store} is
    installed.
\end{itemize}

\subsubsection{Options Menu}\label{subsubsec:app-info-options-menu}
Options-menu is located in the top-right corner of the page. A complete description of the options present there are
given below:
\begin{itemize}
    \item \textbf{Share.} Share button can be used to share the APK file or \textit{APKS} file (if the app is has
    multiple splits) can be imported into \href{https://github.com/Aefyr/SAI}{SAI}. You can share it with your favourite
    file manager to save the file in your shared storage.

    \item \textbf{Refresh.} Refreshes the App Info tab.
    \item \textbf{View in Settings.} Opens the app in Android Settings.
    \item \textbf{Backup/Restore.} Opens the backup/restore dialog.
    \item \textbf{Export Blocking Rules.} Export rules configured for this app within App Manager.

    \item \textbf{Open in Termux.} Opens the app in Termux. This actually runs \texttt{su - user\_id} where
    \texttt{user\_id} denotes the app's kernel user ID (described in the
    \hyperref[subsubsec:app-info-general-information]{General Information section}). This option is only visible to the
    root users. See \Sref{subsubsec:config-termux} to learn how to configure Termux to run commands from third-party applications.

    \item \textbf{Run in Termux.} Open the app using \texttt{run-as package\_name} in Termux. This is only applicable
    for the debuggable apps and works for both root and ADB users. See \Sref{subsubsec:config-termux} to learn how to
    configure Termux to run commands from third-party applications.

    \item \textbf{Extract Icon.} Extract and save the app's icon in your desired location.
\end{itemize}

\subsubsection{Termux}\label{subsubsec:config-termux}
By default, Termux does not allow running commands from third-party applications. To enable this option, you have to add
\texttt{allow-external-apps=true} in \texttt{\textasciitilde/.termux/termux.properties}, and make sure that you are
running Termux v0.96 or later.

\begin{tip}{Info}
    Enabling this option does not weaken your Termux' security. The third-party apps still need to request the user to
    allow running arbitrary commands in Termux like any other dangerous permissions.
\end{tip}

\subsection{Component Tabs}\label{subsec:component-tabs}
\textbf{Activities}, \textbf{Services}, \textbf{Receivers} (originally \textit{broadcast receivers}) and
\textbf{Providers} (originally \textit{Content Providers}) are together called the application components. This is
because they share similar features in many ways. For example, they all have a \textit{name} and a \textit{label}.
Application components are the building blocks of any application, and most of these have to declared in the application
manifest. Application manifest is a file where application specific metadata are stored. The Android operating system
learns what to do with an app by reading the metadata. Colours used in these tabs are explained in
\Sref{subsec:app-details-colour-codes}. You also have the ability to sort the list of components to display blocked or
tracker components on top of the list using the \textbf{Sort} option in the overflow menu.

\subsubsection{Activities}\label{subsubsec:activities}
\textbf{Activities} are windows or pages that you can browse (for instance \textit{Main page} and \textit{App Details
page} are two separate activities). In other words, an activity is a user interface (UI) component. Each activity can
have multiple UI components known as \textit{widgets} or \textit{fragments}, and similarly, each of these latter
components can have multiple of them nested or on top of each other. But an activity is the \textit{master} component:
There cannot be two nested activities. An application author can also choose to open external files within an activity
using a method called \textit{intent filters}. When you try to open a file using your file manager, either your file
manager or system scans for intent filters to decide which activities can open that particular file and offers you to
open the file with these activities (therefore, it is nothing to do with the application itself). There are other intent
filters as well.

Activities which are \textit{exportable} can be usually opened by any third-party apps (some activities require
permissions, if that is the case, only an app having those permissions can open them). In the \textit{Activities} tab,
the name of the activity (on top of each list item) is actually a button. It is enabled for the \textit{exportable}
activities and disabled for others (root users can open any activities). You can click on the button to open the
activity directly in App Manager. You can also open the Interceptor page by long clicking on an activity. Currently, it
only works for \textit{exportable} activities.

\begin{warning}{Notice}
    If you are not able to open any activity, chances are it has certain dependencies which are not met, e.g.\ you
    cannot open  \textit{App Details Activity} because it requires that you at least supply a package name. These
    dependencies cannot always be inferred programmatically. Therefore, you cannot open them using App Manager.
\end{warning}

You can also create shortcut for these \textit{exportable} activities (using the dedicated button), and if you want, you
can edit the shortcut as well using the \textit{Edit Shortcut} button.

\begin{danger}{Caution}
    If you uninstall App Manager, all shortcuts created by App Manager will be lost.
\end{danger}

\subsubsection{Services}\label{subsubsec:details:servcies}
Unlike \hyperref[subsubsec:activities]{activities} which users can see, \textbf{Services} handle background tasks. If
you're, for example, downloading a video from the internet using your phone's Internet browser, the Internet browser is
using a foreground service to download the content.

When you close an activity, it usually gets destroyed immediately (depending on many factors such as how much free
memory your phone has). But services can be run for indefinite periods if desired. If more services are running in
background, your phone will get slower due to shortage of memory and/or processing power, and your phone's battery can
be drained more quickly. Newer Android versions have a battery optimisation feature enabled by default for all apps.
With this feature enabled, the system can randomly terminate any service.

By the way, both activities and services are run in the same \href{https://stackoverflow.com/questions/7597742}{looper}
called the main looper, which means the services are not really run in the background. It's the application authors job
to ensure that. How do application communicate with services? They use
\hyperref[subsubsec:app-details-receivers]{broadcast receivers}.

\subsubsection{Receivers}\label{subsubsec:app-details-receivers}
\textbf{Receivers} (also called \textit{broadcast receivers}) can be used to trigger execution of certain tasks for
certain events. These components are called broadcast receivers because they are executed as soon as a broadcast message
is received. These broadcast messages are sent using a method called intent. Intent is a special feature for Android
which can be used to open applications, activities, services and send broadcast messages. Therefore, like
\hyperref[subsubsec:activities]{activities}, broadcast receivers use intent filters to receive only the desired
broadcast message(s). Broadcast messages can be sent by either system or the app itself. When a broadcast message is
sent, the corresponding receivers are awakened by the system so that they can execute tasks. For example, if you have
low memory, your phone may freeze or experience lags for a moment after you enable mobile data or connect to the Wifi.
Ever wondered why? This is because broadcast receivers that can receive `android.net.conn.CONNECTIVITY\_CHANGE` are
awakened by the system as soon as you enable data connection. Since many apps use this intent filter, all of these apps
are awakened almost immediately by the system which causes the freeze or lags. That being said, receivers can be used
for inter-process communication (IPC), i.e., it helps you communicate between different apps (provided you have the
necessary permissions) or even different components of a single app.

\subsubsection{Providers}\label{appdetails:providers}
\textbf{Providers} (also called \textit{content providers}) are used for data management. For example, when you save an
apk file or export rules in App Manager, it uses a content provider called `androidx.core.content.FileProvider` to save
the APK or export the rules. There are other content providers or even custom ones to manage various content-related
tasks such as database management, tracking, searching, etc. Each content provider has a field called \textit{Authority}
which is unique to that particular app in the entire Android eco-system just like the package name.

\subsubsection{Additional Features for Rooted Phones}
Unlike non-root users who are mostly spectators in these tabs, root users can perform various operations.

\paragraph{Blocking Components}
On the right-most side of each component item, there is a ``block'' icon (which becomes a ``unblock/restore'' icon when
the component is being blocked). This icon (actually, a button) can be used to toggle the blocking status of that
particular component. If you do not have \hyperref[subsubsec:instant-component-blocking]{Instant Component Blocking}
enabled or haven't applied blocking for the app before, you have to apply the changes using the \textbf{Apply rules}
option in three-dots menu. You can also remove already applied rules using the same option (which would be read as
\textbf{Remove rules} this time).

\seealsoinline{\hyperref[sec:faq:app-components]{FAQ: App Components}}

\paragraph{Blocking Trackers}
\phantomsection
\label{par:appdetails:blocking-trackers}
You can disable tracker components using the \textbf{Block tracker} option in the three-dots menu. All tracker
components will be blocked regardless of the tab you're currently in.

\begin{tip}{Info}
    Tracker components are a subset of app components. Therefore, they are blocked using the same method used for
    blocking any other components.
\end{tip}

\begin{amseealso}
    \item \hyperref[subsec:tracker-classes-versus-tracker-components]{FAQ: Tracker classes versus tracker components}
    \item \hyperref[sec:scanner-page]{Scanner Page}
    \item \hyperref[subsec:block-unblock-trackers]{1-Click Ops Page: Block/Unblock Trackers}
\end{amseealso}

\subsection{Permission Tabs}\label{subsec:permission-tabs}
\textbf{App Ops}, \textbf{Uses Permissions} and \textbf{Permissions} tabs are related to permissions. In Android
communication between apps or processes which do not have the same identity (known as \textit{shared id}) often require
permission(s). These permissions are managed by the permission controller. Some permissions are considered
\textit{normal} permissions which are granted automatically if they appear in the application manifest, but
\textit{dangerous} and \textit{development} permissions require confirmation from the user. Colours used in these tabs
are explained in \Sref{subsec:app-details-colour-codes}.

\subsubsection{App Ops}\label{subsubsec:app-ops}
\textbf{App Ops} stands for \textbf{Application Operations}.
Since Android 4.3, \textit{App Ops} are used by Android system to control most of the application permissions.
Each app op has a unique number associated with them which are closed inside first brackets in the App Ops tab.
They also have a private and optionally, a public name.
Some app ops are also associated with \textit{permissions}.
The dangerousness of an app op is decided based on the associated permission, and other information such as
\textit{flags}, \textit{permission name}, \textit{permission description}, \textit{package name}, \textit{group} are
taken from the associated \hyperref[subsubsec:permissions]{permission}.
Other information may include the following:
\begin{itemize}
    \item \textbf{Mode.} It describes the current authorisation status which can be \textit{allow}, \textit{deny} (a
    rather misnomer, it simply means error), \textit{ignore} (it actually means deny), \textit{default} (inferred from
    a list of defaults set internally by the vendor), \textit{foreground} (in newer Androids, it means the app op can
    only be used when the app is running in foreground), and some custom modes set by the vendors (MIUI uses
    \textit{ask}, for instance).

    \item \textbf{Duration.} The amount of time this app op has been used (there can be negative durations whose use
    cases are currently unknown to me).

    \item \textbf{Accept Time.} Last time the app op was accepted.

    \item \textbf{Reject Time.} Last time the app op was rejected.
\end{itemize}

\begin{tip}{Info}
    Contents of this tab are visible to no-root users if \texttt{android.permission.GET\_APP\_OPS\_STATS} is granted via ADB\@.
\end{tip}

There is a toggle button next to each app op item which can be used to allow or deny (ignore) the app op.
If you need to set other modes available to your device, simply long click on an item.
If you need to set additional app ops that are not listed in the tab, use the \textit{Set custom app op} option in the menu.
You can also reset your changes using the \textit{Reset to default} option or deny all dangerous app ops using the
corresponding option in the menu.
You can also sort them in ascending order by app op names and the associated unique numbers (or values).
You can also list the denied app ops first using the corresponding sorting option.

\begin{warning}{Warning}
    Denying an app op may cause the app to misbehave.
    Use the \textit{reset to default} option if that is the case.
    Due to the nature how app ops work, the system may take some time to apply them.
\end{warning}

\seealsoinline{\hyperref[ch:app-ops]{Appendix: App Ops}}

\subsubsection{Uses Permissions}
\textbf{Uses Permissions} are the permissions used by the application. This is named so because they are declared in the
manifest using \texttt{uses-permission} tags. Information such as \textit{flags}, \textit{permission name},
\textit{permission description}, \textit{package name}, \textit{group} are taken from the associated
\hyperref[subsubsec:permissions]{permission}.

\textbf{Root and ADB users} can grant or revoke the \textit{dangerous} and \textit{development} permissions using
the toggle button on the right side of each permission item. They can also revoke dangerous permissions all at once
using the corresponding option in the menu. Only these two types of permissions can be revoked because Android doesn't
allow modifying \textit{normal} permissions (which most of them are). The only alternative is to edit the app manifest
and remove these permissions from there.

\begin{tip}{Info}
    Since dangerous permissions are revoked by default by the system, revoking all dangerous permissions is the same as
    resetting all permissions.
\end{tip}

\begin{tip}{Notice}
    Permissions cannot be changed for apps targeting API 23 or earlier. Therefore, permission toggles are disabled for
    such apps.
\end{tip}

Users can sort the permissions by permission name (in ascending order) or choose to display denied or dangerous
permissions at first using the corresponding options in the menu.

\subsubsection{Permissions}\label{subsubsec:permissions}
\textbf{Permissions} are usually custom permissions defined by the app itself. It could contain regular permissions as
well, mostly in old applications. Here's a complete description of each item that is displayed there:
\begin{itemize}
    \item \textbf{Name.} Each permission has a unique name like \texttt{android.permission.INTERNET} but multiple app
    can request the permission.

    \item \textbf{Icon.} Each permission can have a custom icon. The other permission tabs do not have any icon because
    they do not contain any icon in the app manifest.

    \item \textbf{Description.} This optional field describes the permission. If there isn't any description associated
    with the permission, the field is not displayed.

    \item \textbf{Flags.} (Uses the flag symbol or \textbf{Protection Level} name) This describes various permission flags such
    as \textit{normal}, \textit{development}, \textit{dangerous}, \textit{instant}, \textit{granted}, \textit{revoked},
    \textit{signature}, \textit{privileged}, etc.

    \item \textbf{Package Name.} Denotes the package name associated with the permission, i.e.\ the package that defined
    the permission.

    \item \textbf{Group.} The group name associated with the permission (if any). Newer Androids do not seem to use
    group names which is why you'll usually see \texttt{android.permission-group.UNDEFINED} or no group name at all.
\end{itemize}

\subsection{Signatures Tab}\label{subsec:signatures-tab}
\textbf{Signatures} are actually called signing info. An application is signed by one or more singing certificates by
the application developers before publishing it. The integrity of an application (whether the app is from the actual
developer and isn't modified by other people) can be checked using the signing info; because when an app is modified by
a third-party unauthorised person, the app cannot be signed using the original certificate(s) again because the signing
info are kept private by the actual developer. \textit{How do you verify these signatures?} Using checksums. Checksums
are generated from the certificates themselves. If the developer supplies the checksums, you can match the checksums
using the different checksums generated in the \textbf{Signatures} tab. For example, if you have downloaded App Manager
from Github, Telegram Channel or IzzyOnDroid's repo, you can verify whether the app is actually released by me by simply
matching the following \textit{SHA256} checksum with the one displayed in this tab:
\begin{Verbatim}
    320c0c0fe8cef873f2b554cb88c837f1512589dcced50c5b25c43c04596760ab
\end{Verbatim}

There are three types of checksums displayed there: \textit{MD5}, \textit{SHA1} and \textit{SHA256}.

\begin{danger}{Caution}
    It is recommended that you verify signing info using only \textit{SHA256} checksums or all three of them. DO NOT
    rely on \textit{MD5} or \textit{SHA1} checksums only as they are known to generate the same results for multiple
    certificates.
\end{danger}

\subsection{Other Tabs}\label{subsec:other-tabs}
Other tabs list android manifest components such as features, configurations, shared libraries, and signatures. A
complete description about these tabs will be available soon.
